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' I 'he Lunar Atmosphere Dust Environment Explorer (LADEE) 1 was a small explorer class 
1 mission that launched Sept 7, 2013 and successfully de-orbited and impacted the moon’s 
surface on April 17, 2014. The spacecraft was the first to launch from a Minotaur 5 and was the 
first deep space mission to launch from the Wallops flight facility. Figure 1 shows the famous 
image of a frog unlucky enough to be launched from the facility at the same time as LADEE. 
The science mission for the spacecraft was to determine the density, composition and variability 
of the lunar exosphere. In addition, it performed a first-of-a-kind demonstration of laser-based 
communications from deep space that exhibited a record downlink rate of 622Mbps from the 
moon. In order to perform the lunar dust surveys, the spacecraft was placed in a retrograde 
equatorial orbit with periapsis between 20 and 60 km. The mission was granted an extension in 
which final science surveys were performed at altitudes as low as 2 km over the moon’s surface. 

The cadence for spacecraft operations was demanding: the moon’s highly inhomogeneous 
gravity field distorted the orbit, the regular maneuvers were subject to strict pay load- induced 
pointing requirements, and there were periodic attitude changes to keep the spacecraft thermally 
safe. This led to a need for high reliability in the operation of the spacecraft while obeying strict 
budget and schedule guidelines. 

To minimize fabrication and design costs, the “modular common bus” spacecraft was 
designed with common structural components that could be connected together to form the 
spacecraft. As seen in Figure 2, LADEE was formed of four such modules: 

• Two “Extension Modules” encasing the propulsion system, 

• The “Bus Module” hosting the radiator assembly where the avionics, the Lunar Dust 
Experiment (LDEX), and the Ultra Violet Spectrometer (UVS) were located, 

• The “Payload Module” which hosted the Neutral Mass Spectrometer (NMS), and the 
and the Lunar Laser Communications Device (LLCD). 

For further details on the mission and spacecraft, please see Hine, Spremo, Turner and Caffrey 11 . 

The philosophy for the flight software development was complementary to the physical 
construction, in that it proceeded with a low-cost rapidly prototyped product-line effort. An 
emphasis was placed on the “best-practices” use of layered, modular software architecture with 
strong re-use of Government Off-The-Shelf (GOTS) and Commercial Off-The-Shelf (COTS) 
components. Guidance, Navigation and Controls (GN&C) engineers utilized model-based 
methods (Mathworks Simulink) to develop high-level spacecraft control functions. Software 
engineers then “auto-coded” the models to the “C” programming language for integration with 
the rest of the software layers. This minimized the opportunity for communication and 
transcription errors between algorithm designers and qualified software developers. The model 
based-methodology also enhanced early prototyping of requirements, enabled validation and 
verification during early stages of development and provided a common platform for 
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communication between subsystems, software engineers and stakeholders. 

The overall layered architecture for the onboard flight software is shown in Figure 3. The 
applications auto-coded out from Simulink modules are shown in yellow, with each control 
application being coded as a separate object. These were automatically integrated with the Core 
Flight Executive (cFE) and Core Flight System (cFS) 111 (blue) using a hand-coded “Simulink 
Interface Layer”. Other hand-code developed for the project included memory scrub, telemetry, 
command and hardware input/out drivers shown in green. The real time operating system used 
here was Vx Works. 

When development of the onboard flight software (OFSW) for the LADEE mission started in 
2008 the applicable NASA procedural requirements for software development and software 
assurance were NASA Procedural Requirement (NPR) 7150.2A and the NASA Software 
Assurance Standard NASA-STD-8739.8. These documents provide the minimum set of 
requirements that projects must perform for all phases of software development. The software 
requirements in NPR 7150.2A were developed by the NASA Office of the Chief Engineer’s 
Software Working Group, and the NPR included the requirement that Class B software (that is, 
software responsible for the successful operation of a robotic spacecraft) “be acquired, developed 
and maintained by an organization with a non-expired CMMI-DEV rating as measured by a 
Software Engineering Institute authorized lead appraiser”. Since the LADEE flight software was 
classified as Class B, the project participated in several CMMI appraisals during the course of 
the mission that resulted in the project’s home division at NASA Ames successfully achieving 
the required CMMI Maturity Level 2 rating in 2010 and again in 2013. NPR 7150.2B and the 
accompanying Software Engineering Handbook also incorporate other industry-wide standards. 
Applicable IEEE standards that are referenced include: 

• IEEE Standard for Configuration Management in Systems and Software Engineering, 
IEEE 828-2012 

• ISO/IEC/IEEE 24765 Systems and software engineering- Vocabulary 

• IEEE 1028, IEEE Standard for Software Reviews and Audits 

• IEEE 1012, IEEE Standard for Software Verification and Validation 

Each of the requirements in NPR 7150.2B is governed by its applicability according to 
software classification and is accompanied in the NASA Software Engineering Handbook 
(https://swehb.nasa.gOv/display/7 1 50/Book+B.+7 1 50+Requirements+Guidance) by its rationale, 
guidance, tailoring for small projects, resources and lessons learned. The Handbook’s 
“resources” section makes explicit the influence of outside standards for each of the 
requirements of NPR 7150.2B. Links are also provided that enable authorized NASA users 
access to the NASA Standards and Technical Assistance Resource Tool (START). START 
provides access to technical standards from specifically contracted Standards Developing 
Organizations (SDOs), such as IEEE. 

For LADEE FSW, the standards infused each of the process areas, but the influence was 
particularly evident in the Software Quality and Validation and Verification areas. As advised 
by the standards, the test reporting system incorporated unit testing, integrated testing, scenarios 
for science operations, maneuvers and fault management testing and implemented full bi- 
directional traceability between requirements, designs, models/code, test scripts and test artifacts. 
We performed testing in many different fidelities ranging from Workstation Simulations 
(WSIM) to Processor In the Loop (PIL) to full Hardware In the Loop (HIL). One particularly 
powerful test system was the “Travelling Road Show” in which we would load the flight 
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software on an Engineering Development Unit (EDU) and test interfaces on-site with our 
payloads and other hardware. We applied custom Simulink Model Advisor checks to ensure 
compliance with our modeling standards and performed static analysis of all hand and 
automatically generated code. We used a formal inspection program to drive out defects in 
requirements, designs, code/models and associated test scripts. 

Despite all of these efforts, a small number of software defects that “escaped” the software 
V&V and the spacecraft I&T cycles into flight. One area of difficulty was misinterpretation of 
Interface Control Documents (ICDs). For instance, right after activation of the spacecraft, the 
fault management system shut down all reaction wheels of the spacecraft. It turns out that a flag 
that we had interpreted as an error flag was instead a warning flag. After careful re-reading of 
the ICD, an update was made to the fault management table to ignore the flag, and the 
spacecraft’s attitude system returned to normal. The star tracker system also exhibited emergent 
behavior, issuing delayed state estimates the closer we got to “Big Bright Objects” such as the 
earth and the moon. This unanticipated behavior required two separate uploads of new state 
estimation software to ignore the delayed and corrupted state estimates from the star tracker. We 
also had one unanticipated reboot of the spacecraft at the end of LLCD operations. It was 
determined that we had used a task lock instead of an interrupt lock inside of an interrupt service 
layer called from the high-speed lasercom interface. For the next mission, we will add this item 
as a specific question for our formal inspection program. 

In the end, the LADEE mission was a great success. The mission accomplished 188 days in 
orbit with approximately 200% of planned science data returned at altitudes as low as 2km. The 
spacecraft endured a lunar eclipse that it had not been designed to survive. We utilized our star 
tracker in an unplanned and unusual way, taking close-up pictures of the lunar surface. The 
Lunar Reconnaissance Orbiter (LRO) imaged us in orbit (http://lroc.sese.asu.edu/posts/736). 
We uploaded a complete new build of the flight software that corrected all of the known defects 
and completed the final month of orbital maintenance maneuvers, science operations and 
survived the eclipse with no further software defects found. LADEE was successfully deorbited 
and impacted the moon on the eastern rim of Sundman V crater on April 18, 2014. Our final 
resting place, currently just in sight of earth, was confirmed by post-impact images from LRO 
(http ://l roc. sese . asu . ed u/posts/822) . 
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Figure 1. Frog being ’’launched” at the same time as LADEE 
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Figure 2. Picture of LADEE observatory, showing payloads and purpose of each assembly module. 
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FSW Architecture 
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Figure 3. Layers of the Onboard Flight Software 
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